From wang!elf.wang.com!ucsd.edu!packet-radio-relay Sun Feb 3 18:01:39 1991 remote 
from tosspot 
Received: by tosspot (1.63/waf) 
via UUCP; Sun, 03 Feb 91 19:32:04 EST 
for lee 
Received: from somewhere by elf.wang.com id aa15380; Sun, 3 Feb 91 18:01:38 GMT 
Received: from ucsd.edu by uunet.UU.NET (5.61/1.14) with SMTP 
id AAQ5451; Sun, 3 Feb 91 12:31:23 -0500 
Received: by ucsd.edu; id AA04587 
sendmail 5.64/UCSD-2.1-sun 
Sun, 3 Feb 91 04:30:18 -0800 for hpbbrd!dbOsao!dg4scv 
Received: by ucsd.edu; id AAQ4568 
sendmail 5.64/UCSD-2.1-sun 
Sun, 3 Feb 91 04:30:09 -0800 for /usr/lib/sendmail -oc -odb -0Q/var/spool/ 
lqueue -oi -fpacket-radio-relay packet-radio-list 
Message-Id: <9102031230.AA04568@ucsd.edu> 
Date: Sun, 3 Feb 91 04:30:06 PST 
From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu> 
Reply-To: Packet-Radio@ucsd.edu 
Subject: Packet-Radio Digest V91 #33 
To: packet-radio@ucsd.edu 


Packet-Radio Digest Sun, 3 Feb 91 Volume 91 : Issue 33 


Today's Topics: 
HELP with compiling Xenix SysV NET. 
PACKET->Internet Gateway 
recommended NOS version? 
Shareware on Packet 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 3 Feb 91 01:44:31 GMT 

From: munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@uunet.uu.net (Carl 
Makin) 

Subject: HELP with compiling Xenix SysV NET. 

To: packet-radio@ucsd.edu 


Hi, 

I got a copy of the System V version of Net from TOMCAT for the house 

Xenix system here and am having a REAL problem compiling it. The code seems 
to compile OK but before I actually get to compiling it the MAKE program 
falls over screaming "out of memory". :-( 


Now I'm reasonably new to Xenix/Unix and C but as far as I can see the 
only solutions would be either to compile it manually (urk) or split the 
makefile. 


Has anyone else had this sort of problem? 


The machine I'm trying to compile it on is a 12Mhz 80286 running SCO Xenix 
2.2.3 in 2.5Mb of RAM and 105Mb of Hard disk. 


(Hopefully in a couple of weeks we can borrow 8Mb of RAM for a couple of days 
but I'm not sure that will help. :-( ) 


Carl. 


Date: 2 Feb 91 20:43:50 GMT 

From: zaphod.mps.ohio-state.edu!rpi!uupsi!uhasun! jbloom@tut.cis.ohio-state.edu 
(Jon Bloom) 

Subject: PACKET->Internet Gateway 

To: packet-radio@ucsd.edu 


In article <253@platypus.uofs.edu>, bill@platypus.uofs.edu (Bill Gunshannon) 
writes: 


I have heard numerous times that because the remote station would be 
controlling the transmitter and he is (possibly) a non-ham that this 
would be illegal. Now lets look at this from a practical technical 
aspect. 


If I put up a 10M <-> 2M cross-band repeater, a TECH can come on 2M 

and initiate a contact on 10M. This is not considered illegal although 
the TECH is initiating the contact. I have heard that this is OK under 
the rules covering 3rd Party traffic cause the TECH isn't the control 
operator of the 10M station. Well, I'm sorry, but that doesn't wash 
either. Cause then all the 10M contacts with G-land AND DL-land etc. 
are illegal cause we don;t have 3rd party agreements with them. The 
fact of the matter is that the TECH on 2M never has control of the 
signal generated on 10M and that is why the FCC allows it. I think 


VV VV VV VV VV VV VV WV 


The reason this doesn't fall under the normal third-party rules is that 


the FCC has made explicit exceptions in the case of repeaters. While 
third-party traffic normally requires a control operator to be 

present at the control point (see 97.109), automatic control of a 
repeater is explicitly allowed [see 97.205(d)]. In the case of the 
cross-band repeater with an output on 10m, the Technician cannot be 
the control operator. Fortunately, since a repeater is allowed to 

be under automatic control, no control operator is needed. But if 

the originating signal is not coming from an amateur station, as would 
be the case with Internet-originated data, the station is not, by 
definition, a repeater [see 97.3(a)(34)]. So the analogy between cross- 
band repeaters and an Internet gateway is false. 


the time has come to look at possible INTERNET<->AMPR gateways the same 

way. If it takes letters to the FCC to convince them then so be it. 

If I put up such a gateway, I am controling the emissions of the transmitter 
not the guy in Odessa, TX who sent a message to one of the hams on the 

local LAN. 


VVVV Vv 


But you are *not* controlling the content of the messages being transmitted 
by your station. No ham is controlling that, and therein lies the problem. 


As long as all other rules are abided by, I can't see where there is any 
kind of legal problem. I don't see a lot of difference between this and 

NTS traffic which is non-ham (Happy Birthday, Merry Christmas etc.) put is 
placed into the amateur system at one point by a ham. Basicly the same 
should apply to gateways. I would be considered the ham putting the traffic 
into the amateur system. 

The potential gain would be great. Hams would be able to exchange ideas 

and colaborate with hams and non-hams alike in their technological projects. 


VVVVNVV VV 


I completely agree with your last statement. But there *isx a legal 
difference between the gateway and the NTS example. See below. 


[...Internet legalities deleted] 


So, would someone out there care to show me the error of my ways?? :-) 
I'm not interested in "Well, it you just can't do it, so there." 

I want concrete evidence that shows that the arguments that apply to one 
type of technology (cross-band repeaters) can't be applied to a new 
technology. 


VVVV WV 


At the risk of (once again) being accused of being a technology-bashing, 
Luddite, ARRL old fart, let me try to (once again) explain how it is that 
the existing rules unfortunately prohibit unattended Internet->AMPR 
gateways. 


97.109(e) allows packet stations operating above 50 MHz to pass third- 
party traffic under automatic control, but "The retransmitted messages 


must originate at a station that is being locally or remotely controlled." 
Even worse, messages originated by non-hams (where the notion of a control 
operator can't possibly be stretched to cover the originator) surely come 
under the requirements of 97.115(b) which states in part: 


(b) The third party may participate in stating the message where: 
(1) The control operator is present at the control point and is 
continuously *xmonitoring* and supervising the third party's 
participation. [Emphasis mine. ] 


This means that, under the current rules, you have to monitor (read) 
the data being sent by the Internet participant. A bit difficult in 
an IP gateway! 


Once again... cross-band repeaters are repeaters and fall under the 
repeater rules. An Internet gateway is *xnotx a repeater and does 

xnot*x fall under these rules. The reason the repeater rules were 

created in the first place was to provide relief from the third- 

party rules when only relay of xamateurx signals was involved. Trying 

to interpret these rules in some way that would allow automatic relay 

of nonamateur signals violates both the spirit and letter of the repeater 
rules. Sorry. 


Jon Bloom, KE3Z | American Radio Relay League 
Internet: jbloom@uhasun.hartford.edu | 
Snail: 225 Main St., Newington, CT 06111 | "I have no opinions." 


Date: 2 Feb 91 21:17:02 GMT 

From: modcomp!dan@uunet.uu.net (Dan Grostick) 
Subject: recommended NOS version? 

To: packet-radio@ucsd.edu 


Can anyone recommend their favorite NOS version and where to get 
it from. I have access to uunet but not directly to internet - 
except via a ftp-request mechanism that requires internet address 
and file names. 

Thanks 


-Dan 


N4IXP 


Date: 2 Feb 91 17:10:00 GMT 

From: zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory !wa4mei! ke4zv! 
gary@tut.cis.ohio-state.edu (Gary Coffman) 

Subject: Shareware on Packet 

To: packet-radio@ucsd.edu 


In article <1991Jan31.044034.21294@maverick.ksu.ksu.edu> steve@matt.ksu.ksu.edu 
(Steve Schallehn) writes: 

>A question was posed to me by an amateur who is interested in getting 

>into packet. It seems he has a large collection of shareware on his 
>land-line BBS and he was wondering if he could legally set up his 

>BBS on packet and allow shareware downloads. 

> 

>I know about the avoiding business in amateur radio, but does 

>shareware count? 


Shareware authors ask for and expect money for their product just like 
any other business. They're just freeloading their marketing dept off 
on to the public access systems. While shareware is probably the most 
often pirated software, it's still a commercial product. Therefore it 
would certainly be illegal to distribute it over amateur radio. Think 
of shareware as digital pizzas. :-) 


On the other hand, true freeware and public domain software are perfectly 
ok to send over amateur radio. 


Gary KE4ZV 


End of Packet-Radio Digest 
KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


